Features of Computer-based Clinical Decision Support

The purpose of this chapter is to dig deeper into the nature of computer-based clinical decision support, in terms of the ways in which it is or potentially could be used, its design, and its interaction with host environments. I believe that understanding these aspects of CDS is important as a foundation for serious efforts to increase its dissemination and adoption. As pointed out in previous chapters, and as will be explored in more detail in Section II, much of the success with CDS has been with on-off implementations that have been difficult to maintain over time even within their own institutions, more problematic when extended for use throughout a health care enterprise, and only rarely replicated elsewhere despite demonstrated effectiveness. If we are to tackle this issue and break down barriers to dissemination and adoption, we need to know what we are working with, which aspects are most troublesome and how they can be improved, and which components or interfaces can be standardized or made easier to deploy. We also need to understand the human factors and process and workflow implications of CDS use, so that we can determine optimal approaches to invocation and user interface design. An underlying thesis is that CDS has a conceptual architecture comprised of a number of design elements or components. Many kinds of CDS are designed without the architecture being explicit, but I will try to demonstrate that all the design elements nonetheless are present, even if implicit. A second thesis is that CDS does not function in isolation, but rather that it operates in the context of some sort of application environment. However, in the discussion to follow, I will consider the chunk of software that provides CDS as a ‘‘module’’ of software that interacts with the application environment, recognizing full well that often CDS implementations are not modular at all, and that the dividing line between what constitutes CDS and what constitutes the application that invokes it is not clearly defined, so that the two cannot be cleanly separated. Even so, we can think of the functions that are performed as being done by either the application environment or by the CDS software, so that responsibilities for these functions can be assigned to one or the other. These two conceptual idealizations—1) an underlying component architecture for CDS, and 2) modularity of CDS in that its tasks and responsibilities can be separated from those of the application environment with which it interacts—are helpful to better understand how to design CDS in a portable,